關於 ORM 的定義及優缺點，網路上已經有一堆的說明，我就不在重複囉嗦了，各為童鞋可以自行 Google 或參考下面幾篇 blog

ORM介紹及ORM優點、缺點
http://blog.twbryce.com/what-is-orm/

ORM VS SQL
https://dotblogs.com.tw/code6421/2009/02/10/7100

好用的微型 ORM：Dapper
https://www.huanlintalk.com/2014/03/a-micro-orm-dapper.html

Nodejs最好的ORM - TypeORM
https://cloud.tencent.com/developer/article/1012625

簡單的整理幾個 ORM 重點

1.用物件導向操作資料庫
2.透過 ORM 框架，建立 MVC 架構中的 Model(或反向產生 Schema)

以上這2點，事實上都是近年來開發方法論中的最重要的主流，希望讓系統的開發更標準化、更邏輯化。這絕對是正確的方向，但是條條大路通羅馬，要到羅馬當然不只一條路，搭飛機可能更加便利。

ORM 最常被應用的實際場景(但不限於)，最常見的是表單基本的 CRUD，也就是資料的

新增(Create)
查詢(Read)
修改(Update)
刪除(Delete)。

這當然是非常重要且基本的功能，大部分的 ORM 也都能很輕鬆地完成上面的功能。但是我實在不喜歡 Model 中長串的 GET/SET 設定，雖然有很多的工具可以協助產生。

目前市面上已經有非常多的 ORM 框架，也各有優缺點及擁護者，因為我沒有深入的使用，所以當然沒有資格提出意見。如果想要深入的使用任何一個框架，都必須花很大的力氣才能成為專家，一般基礎的需求都不會造成困壤，很快就能上手，但是有點經驗的 Developer 就會知道，魔鬼隱藏在細節中，碰到較奇怪的 bug 時，在初階學習階段，常常會求救無門，或是框架本身就沒有考慮到某些較特殊的需求。

基於以上的種種原因，我個人一直都沒有真的將 ORM 框架導入到實際的系統開發。但是，ORM 的確會帶來很好的開發體驗，一些例行性的通用功能(如 CRUD)，的確是 ORM 的強項，加上我個人還算精通 SQL，所以很自然地就會想到要用 SQL(Store Procedure) 來實作 ORM 的相關功能。

將 ORM Store Procedure 化(實作) 最大的優點，大概說明如下

1.不必引用任何框架，無學習成本
2.不需要寫任何 Model 的設定程式
3.配合 RESTFul API 架構下，任何前端都能輕易整合(Ajax)
4.使用 Angular 或 Vue 等新漸進式框架的雙向綁定，幾乎完全物件導向化

今天的主題是要引出明天的實作內容。事實上，將 ORM Store Procedure 化，是我不斷強調的「以資料庫為開發核心」的一個非常重要的實作，透過這個實作，您會發現，前端程式變得非常單純，只是在需要時呼叫 API，而後端程式的開發，是先將通用的 Store Procedure 先共用模組化，無法共用的，再依需求寫成 Store Procedure。

在這樣的架構下，所需要學習的開發工具被大幅簡化。誠如我在報名時的前言所說

太過複雜的架構及方法，通常表示這個方案只是過渡技術，因為還沒收斂
人類文明的進步歷程，事實上是善用工具的過程，而究其根本，就是想偷
懶(效率)。

整個系列文我也不斷的反覆說明這個觀念，如果要學習一堆的技術才能開發一個小系統，這絕對是有問題的。應該是只要學會幾個重要的核心工具，就可以搞定大部分的系統才對。當然，筆者才疏學淺，很多概念仍在摸索、學習，僅此與各位童鞋共勉。今天先聊到這，明天繼續努力。